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PROTOCOL EXTENSION SCHEME FOR WIRELESS COMPUTER NETWORKS 

RELATED APPLICATION 

This application is related to and hereby claims the priority benefit of a co-pending 
5 application, Serial No. 09/151,452, entitled Hierarchical Computer Network Architecture, filed 
September 11, 1998, and assigned to the Assignee of the present invention. 

FIELD OF THE INVENTION 

The present invention relates generally to communications in a computer network and, in 
1 0 particular, to a method for extending protocol capabilities within such a network using 
specialized packet header information. 

BACKGROUND 

In the above-referenced co-pending application, Serial No. 09/151,452, which is 
1 5 incorporated herein by reference, a computer network adapted for use in the home environment 
was described. That architecture included a number of network components arranged in a 
hierarchical fashion and communicatively coupled to one another through communication links 
operative at different levels of the hierarchy. At the highest level of the hierarchy, a 
communication protocol that supports dynamic addition of new network components at any level 
20 of the hierarchy according to bandwidth requirements within a communication channel operative 
at the highest level of the network hierarchy is used. Preferably, the communication channel is 
supported on a wireless communication link. 

The generalization of this network structure is shown in Figure 1. A subnet 10 includes a 
server 12. In this scheme, the term "subnet" is used describe a cluster of network components 
25 that includes a server and several clients associated therewith (e.g., coupled through the wireless 
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1. J 

communication link). Depending on the context of the discussion however, a subnet may also 
refer to a network that includes a client and one or more subclients associated therewith. A 
"client" is a network node linked to the server through the wireless communication link. 
Examples of clients include audio/video equipment such as televisions, stereo components, 
5 personal computers, satellite television receivers, cable television distribution nodes, and other 
household appliances. 

Server 12 may be a separate computer that controls the communication link, however, in 
other cases server 12 may be embodied as an add-on card or other component attached to a host 
computer (e.g., a personal computer) 13. Server 12 has an associated radio 14, which is used to 

1 0 couple server 12 wirelessly to the other nodes of subnet 10. The wireless link generally supports 
both high and low bandwidth data channels and a command channel. Here a channel is defined 
as the combination of a transmission frequency (more properly a transmission frequency band) 
and a pseudo-random (PN) code used in a spread spectrum communication scheme. In general, a 
number of available frequencies and PN codes may provide a number of available channels 

1 5 within subnet 10. As is described in the co-pending application cited above, servers and clients 
are capable of searching through the available channels to find a desirable channel over which to 
communicate with one another. 

Also included in subnet 10 are a number of clients 16, some of which have shadow 
clients 18 associated therewith. A shadow client 18 is defined as a client which receives the 

20 same data input as its associated client 16 (either from server 12 or another client 16), but which 
exchanges commands with server 12 independently of its associated client 16. Each client 16 has 
an associated radio 14, which is used to communicate with server 12, and some clients 16 may 
have associated subclients 20. Subclients 20 may include keyboards, joysticks, remote control 
devices, multi-dimensional input devices, cursor control devices, display units and/or other input 

25 and/or output devices associated with a particular client 16. A client 16 and its associated 
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subclients 20 may communicate with one another via communication links 21 , which may be 
wireless (e.g., infra-red, ultrasonic, spread spectrum, etc.) communication links. 

Each subnet 10 is arranged in a hierarchical fashion with various levels of the hierarchy 
corresponding to levels at which intra-network component communication occurs. At a highest 
5 level of the hierarchy exists the server 12 (and/or its associated host 13), which communicates 
with various clients 16 via the wireless radio channel. At other, lower levels of the hierarchy the 
clients 16 communicate with their various subclients 20 using, for example, wired 
communication links or wireless communication links such as infrared links. 

Where half-duplex radio communication is used on the wireless link between server 12 

1 0 and clients 16, a communication protocol based on a slotted link structure with dynamic slot 
assignment is employed. Such a structure supports point-to-point connections within subnet 10 
and slot sizes may be re-negotiated within a session. Thus a data link layer that supports the 
wireless communication can accommodate data packet handling, time management for packet 
transmission and slot synchronization, error correction coding (ECC), channel parameter 

1 5 measurement and channel switching. A higher level transport layer provides all necessary 
connection related services, policing for bandwidth utilization, low bandwidth data handling, 
data broadcast and, optionally, data encryption. The transport layer also allocates bandwidth to 
each client 16, continuously polices any under or over utilization of that bandwidth, and also 
accommodates any bandwidth renegotiations, as may be required whenever a new client 16 

20 comes on-line or when one of the clients 16 (or an associated subclient 20) requires greater 
bandwidth. 

The slotted link structure of the wireless communication protocol for the transmission of 
real time, multimedia data (e.g., as frames) within a subnet 10 is shown in Figure 2. At the 
highest level within a channel, forward (F) and backward or reverse (B) slots of fixed (but 
25 negotiable) time duration are provided within each frame transmission period. During forward 
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time slots F, server 12 may transmit video and/or audio data and/or commands to clients 16, 
which are placed in a listening mode. During reverse time slots B, server 12 listens to 
transmissions from the clients 16. Such transmissions may include audio, video or other data 
and/or commands from a client 16 or an associated subclient 20. At the second level of the 
5 hierarchy, each transmission slot (forward or reverse) is made up of one or more radio data 
frames 40 of variable length. Finally, at the lowest level of the hierarchy, each radio data frame 
40 is comprised of server/client data packets 42, which may be of variable length. 

Each radio data frame 40 is made up of one server/client data packet 42 and its associated 
error correction coding (ECC) bits. The ECC bits may be used to simplify the detection of the 

1 0 beginning and ending of data packets at the receive side. Variable length framing is preferred 
over constant length framing in order to allow smaller frame lengths during severe channel 
conditions and vice-versa. This adds to channel robustness and bandwidth savings. Although 
variable length frames may be used, however, the ECC block lengths are preferably fixed. 
Hence, whenever the data packet length is less than the ECC block length, the ECC block may be 

1 5 truncated (e.g., using conventional virtual zero techniques). Similar procedures may be adopted 
for the last block of ECC bits when the data packet is larger. 

As shown in the illustration, each radio data frame 40 includes a preamble 44, which is 
used to synchronize pseudo-random (PN) generators of the transmitter and the receiver. Link ID 
46 is a field of fixed length (e.g., 16 bits long for one embodiment), and is unique to the link, 

20 thus identifying a particular subnet 10. Data from the server 12/client 16 is of variable length as 
indicated by a length field 48. Cyclic redundancy check (CRC) bits 50 may be used for error 
detection/correction in the conventional fashion. 

For the illustrated embodiment then, each frame 52 is divided into a forward slot F, a 
backward slot B, a quiet slot Q and a number of radio turn around slots T. Slot F is meant for 

25 server 12-to-clients 16 communication. Slot B is time shared among a number of mini-slots B i , 
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B2, etc., which are assigned by server 12 to the individual clients 16 for their respective 
transmissions to the server 12. Each mini-slot Bi, B2, etc. includes a time for transmitting 
audio, video, voice, lossy data (i.e., data that may be encoded/decoded using lossy techniques or 
that can tolerate the loss of some packets during transmission/ reception), lossless data (i.e., data 
5 that is encoded/decoded using lossless techniques or that cannot tolerate the loss of any packets 
during transmission/reception), low bandwidth data and/or command (Cmd.) packets. Slot Q is 
left quiet so that a new client may insert a request packet when the new client seeks to log-in to 
the subnet 10. Slots T appear between any change from transmit to receive and vice-versa, and 
are meant to accommodate individual radios' turn around time (i.e., the time when a half-duplex 

1 0 radio 14 switches from transmit to receive operation or vice-versa). The time duration of each of 
these slots and mini-slots may be dynamically altered through renegotiations between the server 
12 and the clients 16 so as to achieve the best possible bandwidth utilization for the channel 
Note that where full duplex radios are employed, each directional slot (i.e., F and B) may be full- 
time in one direction, with no radio turn around slots required. 

1 5 Forward and backward bandwidth allocation depends on the data handled by the clients 

16. If a client 16 is a video consumer, for example a television, then a large forward bandwidth 
is allocated for that client. Similarly if a client 16 is a video generator, for example a video 
camcorder, then a large reverse bandwidth is allocated to that particular client. The server 12 
maintains a dynamic table (e.g., in memory at server 12 or host 13), which includes forward and 

20 backward bandwidth requirements of all on-line clients 16. This information may be used when 
determining whether a new connection may be granted to a new client. For example, if a new 
client 16 requires more than the available bandwidth in either direction, server 12 may reject the 
connection request. The bandwidth requirement (or allocation) information may also be used in 
deciding how many radio packets a particular client 16 needs to wait before starting to transmit 

25 its packets to the server 12. Additionally, whenever the channel conditions change, it is possible 
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to increase/reduce the number of ECC bits to cope with the new channel conditions. Hence, 
depending on whether the information rate at the source is altered, it may require a dynamic 
change to the forward and backward bandwidth allocation. 
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SUMMARY OF THE INVENTION 

In one embodiment, a packet header for use in information packets transmitted 
within a computer network includes a protocol extension field that indicates changes of 
field values and/or lengths within the header. In one example, the protocol extension field 
5 includes two bits. The value of the protocol extension field indicates whether or not the 
packet header has been altered: 00 indicates no alterations, 01 or 10 indicate a 
predetermined change in the content and/or length of the header, and 1 1 indicates dynamic 
negotiation of the field values and/or size. 

In a further embodiment, a communication protocol for a computer network is 
1 0 provided. In this protocol, packets having headers configured to include an indication of 
whether or not field values and/or lengths thereof have been altered from a preestablished 
norm are used. The headers include protocol extension fields, the values of which may be 
used to indicate whether of not the field values and/or lengths have been altered. 

In another embodiment, components of a computer network are notified whether 
1 5 field lengths and/or values of packet headers associated with communication packets 
transmitted between the components have been altered using protocol extension bits 
included within the headers. The above protocol extension values may be used in this 
methodology. 

These and other features and advantages of the present invention will be apparent from a 
20 review of the detailed description and its accompanying drawings that follow. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example, and not limitation, in the figures 
of the accompanying drawings in which: 

Figure 1 illustrates a generalized network structure that is supported by a wireless 

communication protocol; 

Figure 2 illustrates the slotted link structure of the wireless communication protocol used 

within the network shown in Figure 1; 

Figure 3 illustrates a server/client data packet that may be transmitted according to the 
wireless communication protocol of Figure 2; 

Figure 4 illustrates a packet header including a protocol extension bit field for use the 
data packet shown in Figure 3 in accordance with the present scheme; and 

Figure 5 illustrates an example of an extended packet header created using the present 
protocol extension methods. 
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DETAILED DESCRIPTION 

Described herein is a scheme for extending a communication protocol used within a 
computer network. In one embodiment, the scheme is implemented using protocol 
extension bits in headers of packets transmitted within the network. These bits may be 
5 used by network devices to negotiate new header formats with both predefined and new 
fields. In some cases, the packet header fields may be defined and specified, however, 
using the extension bits the sizes of individual fields may be negotiated during a session to 
suit the application needs. The use of such extension bits effectively increases the life of a 
given communication protocol/architecture, while retaining interoperation with legacy 
X 1 0 devices. It should be remembered, however, that although the present scheme is discussed 
! n with reference to certain embodiments illustrated in the above-mentioned drawings, these 

! r: methods and apparatus are merely examples of the broader concepts involved with the 

:u present invention. 

ill 

As indicated above and shown more clearly in Figure 3, server/client data packets 

; If* 3 --* 

Hp 15 42 have three main parts: a header 60, a payload 62 and an error correction coding (ECC) 
i|| block 64. In one embodiment, the header 60 is doubleword (DWORD) aligned so that data 

i jj writes and reads to/from the packet 42 are simplified for hardware implementations. As 

shown further in Figure 4, the header 60 may be a specified length and may include a 
number of fields 66a - 66m (e.g., a number of valid fields and a number of reserved fields 
20 for future expansion). 

Among the packet header fields is a packet type field 66d. The packet type may be 
represented using a number of bits, for example 4 bits, which allows up to 16 different 
packet types to be differentiated. Such type identification is useful because of the varying 
types of information transported within subnet 10. For example, among the supported 
25 packet types may be: Audio, Video, Voice, Generic Real Time Data (from input/output 
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devices), Commands to/from clients 16, Commands to/from the host 13, Generic Lossless 
Non-Real-Time Data, and Network Feature Update packets. The use of packet type field 
66d allows the communication protocol to cater to video, audio, command and some low 
bandwidth data from subclients. Examples of such low bandwidth data include keyboard 
5 input, mouse input, joystick input, etc. 

Unique to header 60 is the protocol extension (E bits) field 66e, which may be set to 
a predetermined value (e.g., all ZEROs) by default. As and when a protocol extension is 
required, for example to either add a new type of service or to extend the length of a certain 
field in header 60, the E bits can be employed. For example, where two E bits are used, the 
1 0 values 01 and 10 may be used to indicate specific changes in the content and/or length of 
header 60. The value 1 1 may then be used for dynamic negotiation of the header content 
and size. 

Dynamic negotiation of packet header size may be accomplished by maintaining 
packet header content lists at some or all of the devices in the network. For example, two 

1 5 such lists may be employed, with the first list containing all the supported fields in the 
packet header, their default positions within the header and their default lengths (e.g., in 
bits). Such a list could be periodically updated as permanent fields are added to or removed 
from the header. The second list would then be a subset of the first list, containing only 
those packet header fields supported in the current session, and the actual position and 

20 length of those fields. 

Now if a client device 16 needs a change in the format of the basic packet header, it 
may use the E bits to indicate the change. For example, upon logging in to the network, or 
even during a current session, the client 16 may transmit a command packet 42 that has the 
E bit field 66e set to a value "00" and request a new packet header format for E = 1 L For 

25 example, the header may have a field not currently being used in the session. 
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Upon receiving a packet 42 with the £bits set to "00", the network master device 
may authenticate the new packet header format as one that is supported and then grant the 
change to the client. This change will be used for packets having E = 1 1 for this client 
(different clients may use E = 1 1 for different packet header formats). This format should 
5 be made known to all the related clients 16 and shadow clients 18, and may also be 

generally broadcast within the network so that other devices have the opportunity to update 
their packet header content lists. 

While the use of E bits of the type described above offers the possibilities of 
extending computer network communication protocols, there are some caveats that should 

1 0 be observed with their implementation. For example, the position of E bits 66e within the 
basic packet header 60 should not be changed. This is because any change in the position 
of the E bits 66e may cause confusion in the network operations. Further, when the E bits 
are employed any resulting changes in the packet header format should be consistent 
throughout all the packets sourced by the corresponding network device(s). In addition, 

1 5 shadow clients 18 will need to adapt to the new packet header format in order to consume 
the packets from the corresponding client device 16. If there are any disagreements, the 
disagreeing device may lose the shadow client connection, unless the source device 
concedes to use only those changes that can be accommodated by all associated shadow 
clients. 

20 As an example of the use of E bits to dynamically negotiate changes in the packet 

header format, consider the case where a Client Session ID (CS-ID) field needs to be 
extended. Ordinarily, as shown in Figure 6, the CS-ID field of a packet header 60 is 
divided into Source CD-ID and Destination CS-ID fields 66a and 66b, respectively. The 
Source CS-ID field 66a may have a predetermined length (e.g., 8 bits) and is regarded as 

25 the session ID of the device that originates the payload data carried in the packet 42. Thus, 
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in the cases of a client transmission, the Source CS-ID will be the client's session ID, and 
so on. The Destination CS-ID field 66b is also a predetermined number of bits (e.g., 8 bits) 
long and is the session ID of the device for which the packet 42 is destined. Thus, in the 
case of a client transmission, the Destination CS-ID may be the session ID of the server 12. 
5 Using an 8-bit CS-ID value provides support for 256 simultaneous clients per 

subnet 10. However, some of the possible CS-ID values may be reserved for various 
purposes (e.g., special vendor client types, etc.). Thus, the actual number of available CS- 
ID values for clients may be lower. This may present a problem for very large subnets, if 
the number of clients to be supported exceeds the available CS-ID values. Thus, in such 
9 1 0 cases, the E bits can be used to negotiate a different CS- ID field length. 
W Where the network master device has to extend the CS-ID fields due to an increase 

W in the number of online client devices, it can do it in any of three ways. First, it can re- 

negotiate with all the client devices to use the E bits and extend their CS-IDs by a few bits. 
Second, the network master device can move only the devices already using set E bits to 
J* 1 5 the new CS-ID format. In such cases, all the devices using the basic packet header format 
n may, upon receipt of a packet, check the packets E bits and, if they are set, ignore the 

\% packet. Then those devices using the E bits will assume the new length for the CS-ID 

fields and, hence, the new format for the header. Third, the network master can force a new 
definition of the basic packet format. The redefinition can also be used to include the 
20 expansion of other fields, if no other changes are required. Preferably, where CS-ID fields 
are expanded due to a large number of online client devices, the network master device will 
notify all the online clients of these enhancements in accordance with this third option. 
This will allow the client devices to adjust their packet header formats to accommodate the 
change while still permitting client devices to use the E bits for other purposes. 
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An example of renegotiated packet header 70 with extensions 72a and 72b to the 
Source and Destination CS-ID fields (respectively), a new ECC type field74, and a new 
SECurity type field 76 is shown in Figure 5. The new header 70 and its contents may have 
been negotiated either with the basic packet header 60 or a pre-negotiated enhanced header 
that was retrieved from a list. The inclusion of the new fields is signaled through the use of 
E bits 66e. When all the negotiations are complete, both the source and destination devices 
can agree to extend the header up to the next BYTE or DWORD boundary of the packet 42. 

In the example shown in the figure, the Source CS-ID field 66a has been expanded 
using extension field 72a. Likewise, the Destination CS-ID field has been expanded using 
extension field 72b. Any of a number of levels of ECC can be specified by the transmitting 
device using the new ECC type field 74. Further, a security type (e.g., encryption 
on/off/type) can be specified using the SEC field 76. 

Thus, a protocol extension scheme for a computer network has been described. The 
scheme is very different from the use of "protocol version" fields that are common in existing 
communication protocols (such as the Internet Protocol), in as much as the present scheme 
allows for dynamic negotiation of header formats during a session. Thus, although discussed 
with reference to certain illustrated embodiments, the present invention should not be limited 
thereby. Instead, the present invention should only be measured in terms of the claims that 
follow. 
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CLAIMS 

What is claimed is: 

11. A packet header for use in information packets transmitted within a computer 

2 network comprising a protocol extension field that indicates changes of field values and/or 

3 lengths within the header. 

^ 1 2. The packet header of claim 1 wherein the protocol extension field comprises two 

2 bits. 

i - S 

' t 1 3 . The packet header of claim 2 wherein a value of 00 in the protocol extension field 

j " y 2 indicates that the packet header is unaltered. 

|: 1 4. The packet header of claim 2 wherein a value of 01 or 10 in the protocol extension 

Ufl 2 field indicates a predetermined change in the content and/or length of the header. 

1 5. The packet header of claim 2 wherein a value of 1 1 in the protocol extension field 

2 indicates dynamic negotiation of the field values and/or size. 

1 6. A communication protocol for a computer network comprising packets having 

2 headers configured to include an indication of whether or not field values and/or lengths 

3 thereof have been altered from a preestablished norm. 

1 7. The communication protocol of claim 6 wherein the headers include protocol 

2 extension fields, the values of which may be used to indicate whether of not the field values 

3 and/or lengths have been altered. 
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1 8. A method comprising indicating to components of a computer network whether 

2 field lengths and/or values of packet headers associated with communication packets 

3 transmitted between the components of the network have been altered using protocol 

4 extension bits included within the headers. 

1 9. The method of claim 8 wherein a value of 00 for the protocol extension bits 

2 indicates that the packet headers have not been altered. 

1 10. The method of claim 8 wherein a value of 01 or 10 for the protocol extension bits 
O 2 indicates that a predetermined change in the content and/or length of the headers has been 
III 3 made. 

|j 1 11. The method of claim 8 wherein a value of 1 1 for the protocol extension bits 

ill 2 indicates that a dynamic change in the content and/or length of the headers is being made. 

;i 1 12. The communication protocol of claim 7 wherein a value of 1 1 for the protocol 

2 extension bits indicates that a dynamic change in the content and/or length of the header is 
^ 3 being made. 

1 13. The communication protocol of claim 12 wherein different components of the 

2 network may use protocol extension bits values of 1 1 for packet header structures unique to 

3 the corresponding component. 
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ABSTRACT 

A packet header for use in information packets transmitted within a computer 
network includes a protocol extension field that indicates changes of field values and/or 
lengths within the header. In one embodiment, the protocol extension field includes two 
bits. The value of the protocol extension field indicates whether or not the packet header 
has been altered: 00 indicates no alterations, 01 or 10 indicate a predetermined change in 
the content and/or length of the header, and 1 1 indicates dynamic negotiation of the field 
values and/or size. Such packets may be used in a communication protocol for the 
computer network. 
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Attorney's Docket No.: 03498.P028 PATENT 
DECLARATION AND POWER OF ATTORNEY FOR PATENT APPLICATION 



As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below, next to my name. 

I believe I am the original, first, and sole inventor (if only one name is listed below) or an original, 
first, and joint inventor (if plural names are listed below) of the subject matter which is claimed and 
for which a patent is sought on the invention entitled 

PROTOCOL EXTENSION SCHEME FOR WIRELESS COMPUTER NETWORKS 

the specification of which 

x is attached hereto. 

was filed on as 

United States Application Number 

or PCT International Application Number 

and was amended on . 

(if applicable) 

I hereby state that I have reviewed and understand the contents of the above-identified 
specification, including the claim(s), as amended by any amendment referred to above. 

I acknowledge the duty to disclose all information known to me to be material to patentability as 
defined in Title 37, Code of Federal Regulations, Section 1 .56. 

I hereby claim foreign priority benefits under Title 35, United States Code, Section 1 1 9(a)-(d), of any 
foreign application(s) for patent or inventor's certificate listed below and have also identified below 
any foreign application for patent or inventor's certificate having a filing date before that of the 
application on which priority is claimed: 

Priority 

Prior Foreign Application(s) Claimed 



(Number) 


(Country) 


(Day/Month/Year Filed) Yes No 


(Number) 


(Country) 


(Day/Month/Year Filed) Yes No 



(Number) (Country) (Day/Month/Year Filed) Yes No 
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i hereby claim the benefit under title 35, United States Code, Section 1 19(e) of any United States 
provisional application(s) listed below 



(Application Number) Filing Date 



(Application Number) Filing Date 

I hereby claim the benefit under Title 35, United States Code, Section 120 of any United States 
application(s) listed below and, insofar as the subject matter of each of the claims of this application 
is not disclosed in the prior United States application in the manner provided by the first paragraph 
of Title 35, United States Code, Section 1 12, 1 acknowledge the duty to disclose all information 
known to me to be material to patentability as defined in Title 37, Code of Federal Regulations, 
Section 1 .56 which became available between the filing date of the prior application and the national 
or PCT international filing date of this application: 



(Application Number) Filing Date (Status -- patented, 

pending, abandoned) 



(Application Number) Filing Date (Status -- patented, 

pending, abandoned) 

I hereby appoint Farzad E. Amini, Reg. No. P42,261; Aloysius T. C. AuYeung, Reg. No. 35,432; Amy M. 
Armstrong, Reg, No. 42,265; William Thomas Babbitt, Reg. No. 39,591 ; Carol F. Barry, Reg. No. 41 ,600; 
Jordan Michael Becker, Reg. No. 39,602; Bradley J. Bereznak, Reg. No. 33,474; Michael A. Bernadicou, 
Reg. No. 35,934; Roger W. Blakely, Jr., Reg. No. 25,831; Gregory D. Caldwell, Reg. No. 39,926; Kent M. 
Chen, Reg. No. 39,630; Lawrence M. Cho, Reg. No. 39,942; Yong S. Choi, Reg. No. P43,324; Thomas M. 
Coester, Reg. No. 39,637; Roland B. Cortes, Reg. No. 39,152; Barbara Bokanov Courtney, Reg. No. 
42,442; Michael Anthony DeSanctis, Reg. No. 39,957; Daniel M. De Vos, Reg. No. 37,813; Robert Andrew 
Diehl, Reg. No. 40,992; Tarek N. Fahmi, Reg. No. 41,402; James Y. Go, Reg. No. 40,621; Richard Leon 
Gregory, Jr., Reg. No. 42,607; Dinu Gruia, Reg. No. P42,996; David R. Halvorson, Reg. No. 33,395; 
Thomas A. Hassing, Reg. No. 36,159; Phuong-Quan Hoang, Reg. No. 41,839; Willmore F. Holbrow ill, 
Reg. No. P41,845; George W Hoover II, Reg. No. 32,992; Eric S. Hyman, Reg. No. 30,139; Dag H. 
Johansen, Reg. No. 36,172; William W. Kidd, Reg. No. 31,772; Michael J. Mallie, Reg. No. 36,591; Andre 
L. Marais, under 37 C.F.R. § 10.9(b); Paul A. Mendonsa, Reg. No. 42,879; Darren J. Milliken, Reg. 
42,004; Thinh V. Nguyen, Reg. No. 42,034; Kimberley G. Nobles, Reg. No. 38,255; Michael A. Proksch, 
Reg. No. 43,021; Babak Redjaian, Reg. No. 42,096; James H. Salter, Reg. No. 35,668; William W. 
Schaal, Reg. No. 39,018; James C. Scheller, Reg. No. 31,195; Anand Sethuraman, Reg. No. P43.351; 
Charles E. Shemwell, Reg. No. 40,171; Maria McCormack Sobrino, Reg. No. 31,639; Stanley W. Sokoloff, 
Reg. No. 25,128; Allan T. Sponseller, Reg. No. 38,318; Judith A. Szepesi, Reg. No. 39,393; Vincent P. 
Tassinari, Reg. No. 42,179; Edwin H. Taylor, Reg. No. 25,129; George G. C. Tseng, Reg. No. 41,355; 
Lester J. Vincent, Reg. No. 31,460; John Patrick Ward, Reg. No. 40,216; Stephen Warhola, Reg. No. 
43,237; Charles T. J. Weigell, Reg. No. 43,398; Ben J. Yorks, Reg. No. 33,609; and Norman Zafman, 
Reg. No. 26,250; my attorneys, and James A. Henry, Reg. No. 41,064; Daniel E. Ovanezian, Reg. No. 
41,236; Glenn E. Von Tersch, Reg. No. 41,364; and Chad R. Walsh, Reg. No. 43,235; my patent agents, 
of BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP, with offices located at 12400 Wilshire Boulevard, 
7th Floor, Los Angeles, California 90025, telephone (310) 207-3800, and James R. Thein, Reg. No. 
31 ,710, my patent attorney; with full power of substitution and revocation, to prosecute this application and 
to transact all business in the Patent and Trademark Office connected herewith. 

Send correspondence to Tarek N. Fahmi , BLAKELY, SOKOLOFF, TAYLOR & 

(Name of Attorney or Agent) 
ZAFMAN LLP, 12400 Wilshire Boulevard 7th Floor, Los Angeles, California 90025 and direct 

telephone calls to Tarek N. Fahmi , (408) 720-8598. 

(Name of Attorney or Agent) 
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I hereby declare that ail statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful false statements may jeopardize the validity of the application or any 
patent issued thereon. 



Full Name of Sole/First Inveflfoi ^ajujqopal R. Gubbi 



Residence Fair Oaks. California 



Inventor's Si 



ignature 




Citizenship India 



Date /(/fflfVfnqi 



(City, State) 



(Country) 



Post Office Address 8842 Winding Way. Apt # 123 



Fair Oaks. California 95628-6467 
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Title 37, Code of Federal Regulations, Section 1 .56 
Duty to Disclose Information Material to Patentability 



(a) A patent by its very nature is affected with a public interest. The public interest is best served, 
and the most effective patent examination occurs when, at the time an application is being examined, the 
Office is aware of and evaluates the teachings of all information material to patentability. Each individual 
associated with the filing and prosecution of a patent application has a duty of candor and good faith in 
dealing with the Office, which includes a duty to disclose to the Office all information known to that individual 
to be material to patentability as defined in this section. The duty to disclosure information exists with respect 
to each pending claim until the claim is cancelled or withdrawn from consideration, or the application becomes 
abandoned. Information material to the patentability of a claim that is cancelled or withdrawn from 
consideration need not be submitted if the information is not material to the patentability of any claim 
remaining under consideration in the application. There is no duty to submit information which is not material 
to the patentability of any existing claim. The duty to disclosure all information known to be material to 
patentability is deemed to be satisfied if all information known to be material to patentability of any claim 
issued in a patent was cited by the Office or submitted to the Office in the manner prescribed by §§1 .97(b)-(d) 
and 1.98. However, no patent will be granted on an application in connection with which fraud on the Office 
was practiced or attempted or the duty of disclosure was violated through bad faith or intentional misconduct. 
The Office encourages applicants to carefully examine: 

(1 ) Prior art cited in search reports of a foreign patent office in a counterpart application, and 

(2) The closest information over which individuals associated with the filing or prosecution of a 
patent application believe any pending claim patentabiy defines, to make sure that any material information 
contained therein is disclosed to the Office. 

(b) Under this section, information is material to patentability when it is not cumulative to 
information already of record or being made or record in the application, and 

(1) It establishes, by itself or in combination with other information, a prima facie case of 
unpatentability of a claim; or 

(2) It refutes, or is inconsistent with, a position the applicant takes in: 

(i) Opposing an argument of unpatentability relied on by the Office, or 

(ii) Asserting an argument of patentability. 

A prima facie case of unpatentability is established when the information compels a conclusion that a claim is 
unpatentable under the preponderance of evidence, burden-of-proof standard, giving each term in the claim 
its broadest reasonable construction consistent with the specification, and before any consideration is given to 
evidence which may be submitted in an attempt to establish a contrary conclusion of patentability. 

(c) Individuals associated with the filing or prosecution of a patent application within the 
meaning of this section are: 

(1 ) Each inventor named in the application; 

(2) Each attorney or agent who prepares or prosecutes the application; and 

(3) Every other person who is substantively involved in the preparation or prosecution of the 
application and who is associated with the inventor, with the assignee or with anyone to whom there is an 
obligation to assign the application. 

(d) Individuals other than the attorney, agent or inventor may comply with this section by 
disclosing information to the attorney, agent, or inventor. 
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